Summary

Closes #142.

WinUI's lifted XAML loader resolves local: namespaces and Generic.xaml type/property references through Application.Current's IXamlMetadataProvider chain. ReactorApplication previously only delegated to Reactor's own generated provider plus a hand-written core stub, so any custom Control declared in the consuming app — or in a referenced third-party library when the consumer has no XAML of its own — went unresolved, and the lifted parser took the process down with Failed to create a 'Microsoft.UI.Xaml.DependencyProperty' from the text 'MyText' before the control could render.

The bug title talks about "readonly dependency properties" but the failure surfaces for any user-defined property whose declaring type isn't reachable through Application.Current's metadata chain — the customer's repro just happened to reduce to a control with one private DP.

What changed

1. Entry-assembly auto-discovery (src/Reactor/Hosting/ReactorApp.cs)

ReactorApplication now scans the entry assembly for any concrete, parameterless-ctor IXamlMetadataProvider (the type the WinUI XAML compiler emits when a project has any XAML file) and chains it between Reactor's own provider and the core stub. Skips Reactor's own generated type to avoid recursion if the entry assembly happens to be Reactor under test hosting. Covers the common case — when the consumer has any XAML file, the compiler-generated OtherProviders list transitively chains every referenced library, so this single discovery brings the whole graph in.

2. Explicit registration API for 3P libraries

For the no-XAML-consumer case, the compiler-generated chain doesn't exist, so referenced libraries can't be reached transitively. Added:

public static void ReactorApp.RegisterControlAssembly(IXamlMetadataProvider provider);
public static void ReactorApp.RegisterControlAssembly(System.Reflection.Assembly assembly);

Idempotent, thread-safe, copy-on-write snapshot semantics so the hot lookup path on the UI thread needs no locking. The Assembly overload reflects out the compiler-generated provider type and instantiates it. Mirrors the Win2D / CommunityToolkit setup pattern in pure WinUI.

// In a no-XAML Reactor app referencing a 3P control library:
ReactorApp.RegisterControlAssembly(typeof(SomeThirdPartyControl).Assembly);
ReactorApp.Run<MyComponent>("My App");

3. Tests

• Issue142_CustomControlPrivateDp_Renders — entry-assembly path. Custom control + Generic.xaml in Reactor.AppTests.Host itself, exercises the auto-discovery.
• Issue142_ThirdPartyControlPrivateDp_Renders — registration path. New standalone library tests/Reactor.AppTests.ThirdPartyControls/ simulates a 3P NuGet (custom control with private DP + Themes/Generic.xaml + {TemplateBinding MyText}). Fixture calls RegisterControlAssembly(...) and asserts both the registration list and the rendered template-bound text.

The 3P fixture's failure mode (process crash without registration in a no-XAML consumer) was verified manually with a temporary throwaway app; the fixture itself passes either way in this test host because the host's own Themes/Generic.xaml triggers the auto-chain. The fixture comment explains this and asserts the registered-provider list is non-empty so the API is at least exercised.

Test plan

• dotnet build Reactor.sln -c Debug — clean.
• Reactor.AppTests.Host.exe --self-test — 2214/2214 ok.
• dotnet test tests/Reactor.Tests — 6793/0 fail.
• Manually verified no-XAML consumer scenario: control renders with RegisterControlAssembly, process crashes without it (matches issue [Bug] Controls with readonly dependency properties are not supported #142 originate error).

🤖 Generated with Claude Code